🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Show the relevant workflow file with line numbers.
if [ -f .github/workflows/sast.yml ]; then
  wc -l .github/workflows/sast.yml
  sed -n '1,220p' .github/workflows/sast.yml | cat -n
else
  echo "File not found: .github/workflows/sast.yml"
  exit 1
fi

Repository: BigSimmo/Database

Length of output: 2298

🌐 Web query:

GitHub Actions job-level continue-on-error failed step checkout container initialization workflow passes without running later steps

💡 Result:

In GitHub Actions, the continue-on-error: true attribute is designed to prevent a job from failing when a specific step fails, allowing subsequent steps in that job to execute [1][2]. If your workflow appears to stop after a step with continue-on-error: true fails, it is likely due to one of the following reasons: 1. Step Outcome vs. Conclusion: When continue-on-error is set to true, the step's outcome will reflect the actual failure (e.g., 'failure'), but the step's conclusion will be 'success' because the error was suppressed [3][4]. If you have subsequent steps that use conditional logic (e.g., if: failure()), they will not run because GitHub Actions evaluates them based on the step's conclusion [3][4]. To detect the failure in later steps, you should check the outcome property instead: if: steps.<step_id>.outcome == 'failure' [2][4]. 2. Container Initialization Issues: If the failure occurs during "container initialization" (e.g., pulling an image, mounting volumes, or setting up the container environment), it may represent a platform-level or infrastructure error that occurs outside the scope of individual step execution. In some cases, if the runner itself cannot initialize the environment for subsequent steps, the job may terminate despite the continue-on-error flag [5]. 3. Nested Action Failure: continue-on-error generally works at the immediate step level [5]. If the failure occurs deep within a nested composite action or a sub-action that itself calls other actions, the continue-on-error flag on the outer step may not successfully mask failures occurring in certain internal processes (such as post-actions or deep-level node scripts) [5]. To troubleshoot, inspect the logs for any error messages occurring after the failed step, as these often indicate if the runner aborted the job due to infrastructure constraints rather than a simple step failure [5].

Citations:

• 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
• 2: https://stackoverflow.com/questions/73706004/mark-a-github-actions-workflow-as-success-even-if-a-step-fails
• 3: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
• 4: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
• 5: continue-on-error in an action doesn't suppress an error from a node action called by an action it calls actions/runner#3510

🌐 Web query:

GitHub Actions jobs.<job_id>.continue-on-error job-level semantics step failures checkout failure workflow conclusion

💡 Result:

In GitHub Actions, the continue-on-error property behaves differently depending on whether it is applied to a specific step or an entire job [1]. For steps, jobs.<job_id>.steps[*].continue-on-error allows a job to continue executing subsequent steps even if the specific step fails [2]. When a step with continue-on-error: true fails, the step's outcome is failure, but its final conclusion is recorded as success [3][4]. This allows the job to proceed, effectively masking the failure at the step level [2]. For jobs, jobs.<job_id>.continue-on-error prevents the entire workflow run from failing if the specific job fails [1]. When set to true, the workflow run is permitted to pass even if that job fails [1]. It is important to note that using continue-on-error does not make the job "succeed" in a technical sense; it primarily affects the workflow's overall completion status [5][4]. Because the job itself may still report a failure internally, conditional expressions like if: failure() or needs.<job_id>.result may behave unexpectedly if you rely on them to detect the "true" outcome of a job [6][5]. The job's internal failure status remains, which can impact dependent jobs if they are configured to run based on the outcome of the job that used continue-on-error [5][7]. If a job fails or is skipped, all downstream jobs that depend on it are typically skipped unless they use conditional expressions to continue [7].

Citations:

• 1: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/workflow-syntax.md
• 2: https://docs.cloudbees.com/docs/cloudbees-unify/latest/dsl-syntax/jobs-job-id-steps-continue-on-error
• 3: https://docs.github.com/en/enterprise-server@3.2/actions/learn-github-actions/contexts
• 4: Please support something like "allow-failure" for a given job actions/runner#2347
• 5: continue-on-error should not return success in needs_job_result actions/toolkit#1739
• 6: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
• 7: https://docs.github.com/actions/using-jobs/using-jobs-in-a-workflow